NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/16054

Internet Message Format | 1996-08-05 | 5.6 KB

Path: news.cyberport.com!usenet
From: [e-mail] (Warren Young)
Newsgroups: comp.lang.c++,rec.games.programmer,alt.msdos.programmer,comp.programming
Subject: Re: Young programmers read me.
Date: Tue, 09 Apr 1996 09:52:51 GMT
Organization: none
Message-ID: <[e-mail]>
References: <4icpp9$[e-mail]> <4imqe4$[e-mail]> <[e-mail]> <4j52hn$[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: ppp5.cyberport.com
X-Newsreader: Forte Agent .99d/32.182

[e-mail] (Aidan Cully) wrote:

>programming and speed, I was only arguing that Pascal has certain things
>over it (e.g. readability and honest-to-God free-form language), and just

Pascal is one of the least free-form languages I know (old Fortran
being the glaring exception, of course).  Consider declaration blocks:
they have to go in a very specific order, and for no really good
reason.  Sure, most modern Pascals throw this rule to the wind, but
that's how it was designed.

I've only seen one argument from you about C's "non-free-form"
attributes, and that was the #define statement.  As someone already
pointed out, it's not really part of the language anyway.  Besides,
C++ fixes that with true constants and inline functions.  Very little
is lost by using these new features to the complete exclusion of
#define.

As for readability: that's subjective.  I can think of any number of
things that are "readable" only to people trained in their
intricacies.  Electrical schematics, for one example.  Yes, Pascal has
a lower learning curve for this, and for that reason is a good
teaching language.  However, C and C++ trade simplicity for expressive
power, which has contributed much to the language's popularity, IMO.

>by abstraction?  C is one of the lowest-level languages there is, and C++
>is just an object-oriented hack put on top of it.

This is a common problem: people not "getting" the philosophy of
C/C++.  First, though, don't get me wrong by thinking that you "must"
agree with C/C++'s philosophy.  I just mean to say that you really
can't responsibly argue for or against C/C++ without first
understanding its philosophy.

Anyway, my point is that C and C++ have the philosophy that they are
just a tool, and it is up to the programmer to use them properly (or
improperly, if they so wish).  Many languages attempt to force the
programmer to write good programs, and they have some merit because of
that.  Unfortunately, you frequently run into problems because the
language designer's idea of a "good program" and yours differs.  The
programmer ends up feeling stifled and overly constrained.

On the other hand, C and C++ don't have much to say about how you
write your program.  You'll find that pretty much every syntax rule of
C/C++ has a solid, unrefuted basis in good design principles.
Controversial tools like goto are provided for those that want them.
But notice that even goto is constrained: you can't jump outside a
function, something that is more-or-less universally agreed to be a
Good Thing.  For those situations where you really do want to break
function barriers, there is setjmp/longjmp.  Both tools are dangerous
but useful -- they're there for when you need them, and you can ignore
them when you don't need them.

In contrast, consider Old BASIC.  Why does no one disagree that it was
a bad language?  Because it didn't provide the tools necessary to
write good programs, not because of the features it did provide.  As
MS and others extended BASIC with functions, looping constructs, local
scoped variables, modules and such, BASIC began to lose some of its
opposition, so that now there are thousands of respected professionals
making their living with BASIC; specifically, VB.

The moral?  C/C++ doesn't necessarily encourage good programming, but
only because it doesn't enforce much of anything related to style.  I
like the C/C++ world's solution to having tools to look over your
shoulder: make them completely external to the language, like lint.
That way, you have both automated protection as well as freedom of
design.  If the checks are built into the language, you don't have
many choices at all: do it the tool's way or don't do it at all.

>C++ is badly designed.  For example, Function pointer will return an
>integer, takes two ints as parameters.  In C/C++
>   typedef (int*)(int a, int b) MyFuncType;
>   MyFuncType MyFunc;
>in Oberon
>   TYPE
>      MyFuncType:FUNCTION( a, b:INTEGER ):INTEGER;
>   VAR
>      MyFunc:MyFuncType;
>Which do you think looks more readable?

Again, this is a philosophical distinction.  C/C++'s function pointers
are low-level, true hardware pointers, not abstracted handles or some
such.  Could you, for example, assign a raw address to the Oberon
sample?  You can in C/C++, because they're directly analogous to the
underlying machine structures.

I'm not saying that function pointers couldn't be made better, as your
Oberon code shows, just that C/C++ wasn't designed with that in mind.
That doesn't mean that it was poorly designed, either.

To summarize: you can't argue about syntax rules without understanding
and taking into account the design goals behind them.  In that
respect, I think C/C++ is okay -- it lives up to its design goals.
Now, if those design goals don't work for you, then you have a problem
all right, but only to the extent that you must find a language that
has "better" design goals.

To summarize the summary: You don't dislike C/C++, its design goals
just aren't compatible with yours.

= Warren --